feat(hosts): add pi coding agent adapter - #675

Thanks for adding a new host adapter. New-host reviews cover several independent seams — installation, scheduler lifecycle and real wake-up behavior, transcript preparation/shape, self-session exclusion, retrieval injection, and cross-platform cleanup — so this review will take longer than an ordinary feature review.

I will validate these areas in order and report them incrementally rather than bundle everything into one pass. There will likely be multiple request-changes rounds as each seam is exercised end to end; that is expected for a host integration and is not a judgment on the overall direction of the contribution. I am starting with installation and scheduler creation/wake-up behavior first.

I tested the Windows install through the real agent-facing path:

1. Removed the existing Pi memU task.
2. Started a fresh Pi session and gave it only the rendered memu-pi docs install guide.
3. Let Pi complete the installation without manual corrections.
4. Confirmed \memU\memu-bridging-pi, its wrapper/prompt files, and retrieval artifacts were created.
5. Triggered the actual S4U Task Scheduler entry and checked Pi sessions, bridge.log, manifests, and jobs.

The installation completed, and both schedule status and schedule verify reported success, but the real scheduled run failed:

LastTaskResult: 1
System.Management.Automation.RemoteException
NativeCommandError: 系统找不到指定的文件。

Content-free wrapper markers showed that Task Scheduler successfully started PowerShell and read bridge-prompt.txt; it failed exactly here:

& '...\pi.CMD' -p $prompt

bridge.log stayed empty, no new Pi session was created, and the manifest/jobs did not advance.

On this machine, Pi is installed through npm. Interactive PowerShell resolves pi to pi.ps1, while the scheduler installer uses shutil.which("pi") and freezes the npm pi.CMD shim into the wrapper. Claude Code works here because its scheduler path is a standalone claude.exe, not a batch shim.

As an isolation test, I changed only the same S4U task invocation to the executable and JS entry point used by the shim:

& '...\node.exe' '...\node_modules\@earendil-works\pi-coding-agent\dist\bundle\cli.js' -p $prompt

That immediately created a new Pi session and advanced the pending manifest and jobs. This confirms that S4U, Pi authentication, the model, and the prompt all work; the blocker is launching the npm .CMD shim.

Please make the Windows scheduler handle .cmd / .bat launchers correctly (or resolve the npm shim to its real executable entry point), preserve the prompt as one argument, and add wrapper coverage for that path. schedule verify should not be treated as end-to-end proof because its auth probe runs in the interactive process rather than the S4U task.

Since your development machine is macOS, please also run the equivalent black-box test there: give a fresh Pi session only memu-pi docs install, inspect the generated cron/launchd registration, trigger the real OS scheduler entry, and verify that bridge.log, a new Pi session, and the manifest/jobs all advance. A manual pi -p or manual wrapper run is not sufficient evidence that cron/launchd can wake the bridge with its non-interactive environment.

Addressed the installation/scheduler review in commit 0da3459.

Windows npm launcher

• When shutil.which() resolves an npm launcher to .cmd / .bat, the scheduler now uses npm's sibling .ps1 shim for the generated PowerShell wrapper. This avoids sending the prompt through cmd.exe; the wrapper invocation remains & '<shim>.ps1' -p $prompt, so the prompt stays one PowerShell argument.
• Installation now refuses a batch launcher with no PowerShell companion instead of registering a task that cannot wake under S4U.
• Added coverage through the complete install -> generated wrapper path for an npm pi.CMD, plus the missing-companion failure path.

schedule verify

• Changed the install/verify output and the Windows scheduler guides to say explicitly that this checks registration plus a current-process headless-auth probe only.
• Successful verify output now says that it did not run the S4U task and requires evidence from bridge.log, a new host session, jobs, and the promoted manifest.

macOS black-box verification

I ran a fresh Pi session with existing context files, skills, extensions, and prompt templates disabled, and supplied only the rendered memu-pi docs install guide. Before the run there was no Pi host directory and no crontab. The agent completed configuration, created the wrapper/prompt and hourly cron entry, installed retrieval, confirmed a fresh Pi session loaded the managed global context, and reported the install successfully.

I then temporarily moved only the generated cron entry to the next minute and let the macOS cron daemon trigger it (not a manual pi -p or wrapper invocation):

• bridge.log: absent -> created -> 777 bytes after exit;
• Pi session count: 53 -> 54 at cron wake-up;
• jobs: 21 leftovers -> 7 newly prepared -> 0 after the final commit;
• pending manifest: 2037 bytes -> 2453 bytes -> removed after promotion;
• promoted manifest: absent -> 2037 bytes after the leftovers commit -> 2453 bytes after the final commit;
• .bridge.lock: present while the cron run was active, absent after clean exit;
• the generated cron entry was restored to its documented hourly 0 * * * * cadence.

The scheduled Pi run reported 28 jobs completed and both commits succeeded.

Validation:

• Windows scheduler tests: 69 passed
• make check: passed
• full suite outside the listener-restricted sandbox: 607 passed, 8 skipped
• git diff --check: passed

Follow-up scope cleanup in c2af7cb: reverted the incidental Claude Code, Cursor, and Hermes BRIDGING_TASK.md edits. The review response is now limited to the shared Windows scheduler implementation/tests and Pi's scheduler guide. Windows scheduler tests remain 69 passed; pre-commit passes.

Addressed the three blocking changes in 85aee52.

• The generated Windows wrapper now invokes the host CLI name (pi) while retaining the resolved path for preflight/auth and for prepending its directory to the S4U task PATH.
• Removed _resolve_scheduled_agent, the .ps1-specific install/verify guards, and their implementation-coupled tests. The replacement install -> generated wrapper regression starts from a resolved pi.CMD and asserts & 'pi' -p $prompt, the PATH prefix, and no frozen .CMD/.ps1 path.
• Removed Pi installation instructions and the separate pi -p authentication probe from Pi's memU install guide.

Validation: Windows scheduler tests 68 passed; make check passed; full suite 606 passed, 8 skipped; git diff --check passed.

I cannot rerun the requested real Windows S4U black-box from this macOS host, so I am not claiming that runtime evidence. The generated-wrapper regression covers the requested CLI-boundary behavior; the real Task Scheduler wake-up still needs confirmation on Windows via the Pi session, bridge.log, jobs, and manifest traces.

Addressed the Pi self-session identity mismatch in 4a3a102.

• PiTranscriptSource.session_id() now removes Pi's timestamp prefix and returns the UUID exported through PI_SESSION_ID.
• Added a source regression using the exact filename shape from the report.
• Added a Pi-specific _cmd_prepare regression with a previously recorded bridge UUID and the marked current UUID. Both timestamp-prefixed transcripts are skipped, and the run writes neither transcript slices nor job files.

Validation: focused host/self-session tests 73 passed; make check passed; full suite 608 passed, 8 skipped; git diff --check passed.

Addressed the Pi prepare-output privacy seam in efc80cf, after rebasing the branch onto current main (54f9468).

• Added a Pi-specific delete-only sanitize() at the shared prepare-output boundary.
• Removed record id, parentId, and timestamp; message api, provider, model, usage, stopReason, rawStopReason, responseId, timestamp, and errorMessage; tool-result details; and content-block thinkingSignature.
• Preserved conversation/tool content and unknown record, message, and content-block fields.
• Added field-level coverage plus a prepare_transcripts integration regression proving prepared conversation/full output is sanitized while the source JSONL remains byte-for-byte unchanged and the pending cursor retains the original line count and timestamp.

Validation: focused host/self-session/scheduler tests 149 passed; make check passed; full suite 646 passed, 8 skipped; git diff --check passed.

Thank you for the careful review.

Addressed the scheduler-auth and custom-session-dir review in 8376fb0.

This is not the Claude Code case. Claude Code needs needs_headless_auth=True because the Desktop login is invisible to standalone claude -p, so the S4U task really does need a persistent CLI credential (setup-token / ANTHROPIC_API_KEY). Interactive pi and scheduled pi -p are the same CLI and share ~/.pi/agent/auth.json; memU should not treat /login, an API key, or a headless-auth probe as an install gate.

• Removed needs_headless_auth=True and auth_hint from the Pi spec, so schedule install / verify no longer run pi -p ping.
• Removed schedule_prepare_session_dir=True. Scheduled prepare stays memu-pi prepare on the default ~/.pi/agent/sessions layout; install-time PI_CODING_AGENT_DIR / PI_CODING_AGENT_SESSION_DIR / settings.json paths are not baked in, and the wrapper is not extended to forward them.
• INSTALL.md / BRIDGING_TASK.md no longer mention a headless authentication probe, custom session directories, or rewriting the scheduled prompt. Verify is task registration plus a real OS run that produces a new Pi session, bridge.log, and jobs/manifest traces.

Validation: focused host/self-session/scheduler tests 185 passed; git diff --check passed.

@xnne-bot Thank you for the careful follow-up.

Addressed the remaining directory-override leak in 5576bad.

8376fb0 stopped baking an install-time path into the scheduled prompt, but sessions.py still read PI_CODING_AGENT_DIR / PI_CODING_AGENT_SESSION_DIR on every memu-pi start. A manual prepare in an env that had those variables would write the cursor against a custom store; the later cron/S4U prepare usually has a clean env and would read ~/.pi/agent/sessions. Same working tree, two sources.

• AGENT_DIR / SESSION_DIR are now the fixed defaults ~/.pi/agent and ~/.pi/agent/sessions. The os import is gone.
• Instruction and skills paths follow that same default through cli.py.
• Custom Pi agent/session directories are out of this adapter: those sessions do not enter memorize/bridging. An explicit, persistent source migration is a later PR, not this one.

Validation: focused host/self-session/scheduler tests 186 passed; git diff --check passed.